\vspace{-0.5cm}
\subsubsection{Dynamic Mapping Rules}
\label{sec:state}describe the mapping between the \emph{policy} entities (roles, actions and contexts) and the \emph{application} entities (instances, fields, methods and their parameters). A \textsf{RoleRule} specifies which instances in the application are assigned to which role in the policy. An \textsf{OperationRule} specifies a correspondence between method calls and policy actions. %(together with their associated parameter values that can be reused through the sequence) realizes an action in the policy. 
A \textsf{ContextRule} defines a policy context as a condition on the application state: the context holds if its \textsf{MatchingExpression} holds on the application state. %The high abstraction level of the Security Rules Language, dynamic mapping rules decouples the application from its security layer, allowing flexibility and portability of the Security Rules. 
In the following, we describe the representation of the \emph{application} and \emph{policy} states (which compose together the \textsc{Pdp} state) in \SAR. Then, we explain how elements of the application state are mapped to elements of the policy state using dynamic mapping rules. 

\begin{figure*}[t]
	\center
	\resizebox{\textwidth}{!}{\includegraphics{DynamicState.png}}	
	\caption{Dynamic State}
	\label{fig:state}
   \vspace{-0.5cm}
\end{figure*}

\paragraph{Application State} At runtime, the state of an application consists of the set of active objects (or instances), the field instance values, and the stack of method calls. To correctly manage the security policy, e.g. activate contextual obligations, changes in the application state that are relevant to the enforcement of the policy need to be monitored. In our architecture, shown in Figure~\ref{fig:approach}, these changes are monitored by the aspect layer within the \textsc{Pep}, which notifies the \textsc{Pdp} when a relevant change is detected. Using the \textsc{Pep}'s notifications, the \textsc{Pdp} maintains a partial representation of the application state. Concretely, this state takes the form of a set of First-Order Logic (\textsc{Fol}) facts, allowing the specification of security policies in \textsc{Fol}.
This state is metamodelled in Figure \ref{fig:state} (left): an \textsf{InstanceFact} represents a class instance; a \textsf{FieldFact} represents an instance field; a \textsf{MethodCallFact}, together with \textsf{ParamFact}s, represents a method call. In \SAR's concrete syntax, these facts are written as follows:

\begin{itemize}
\item \texttt{instance\_of(i,r)}: \textsf{i} is an instance of class \textsf{r}.
\item \texttt{field\_of(i,f,v)}: \textsf{v} is the value of the field \textsf{f} of the instance \textsf{i}.
\item \texttt{call\_of(c,m)}: \textsf{c} is a call of the method \textsf{m}.
\item \texttt{param\_of(c,p,v)}: \textsf{v} is the value of parameter \textsf{p} in the method call \textsf{c}. 
\end{itemize} 
Two special parameters, \textsf{this} and \textsf{target}, are systematically added to the normal parameter list of a method call to denote the calling and called instance respectively.

\paragraph{Policy State} is managed by the \textsc{Pdp} based on the application state. A \textsf{PolicyState} contains security rules that are \emph{applicable}, or \emph{effective} at a given time. Effective security rules are the set of \textsf{ACTIVE} permissions and the set of \textsf{ACTIVE}, \textsf{FULFILLED} or \textsf{VIOLATED} obligations (all values of the \textsf{State} enumeration in Fig. \ref{fig:state}). In \SAR's concrete syntax, a policy state is represented using facts having one of the following forms:
\begin{itemize}
\item \texttt{permitted(r,s,a,o)}: rule \textsf{r} authorizes subject \textsf{s} to take action \textsf{a} on \textsf{o}.
\item \texttt{prohibited(r,s,a,o)}: rule \textsf{r} prohibits \textsf{s} to take \textsf{a} on \textsf{o}.
 \item \texttt{obliged(r,s,a,o,t)}: rule \textsf{r} obliges \textsf{s} to take \textsf{a} on \textsf{o}.
  \item \texttt{obliged(r,s,c,o,t)}: rule \textsf{r} obliges \textsf{s} to maintain \textsf{c} on \textsf{o}.
\end{itemize}

\begin{figure*}[t]
	\center
	\resizebox{\textwidth}{!}{\includegraphics{Predicate.png}}	
	\caption{Rule Condition Language}
	\label{fig:predicate}
\end{figure*}

\paragraph{Dynamic Mapping Rules} If the \textsf{MatchingExpression} of a \textsf{DynamicMappingRule} holds on the application and policy states for some instantiation, i.e. a variable substitution making the \textsf{MatchingExpression} true, then the \textsf{DynamicMappingRule} holds for this instantiation. For example, a \textsf{RoleRule} of the form \texttt{role\_of(I, role\_name) <- instance\_of(I,\-class\_name)} assigns an instance \textsf{x} to the role \texttt{role\_name} when \texttt{instance\_of(x,class\_name)} holds in the current state. Figure~\ref{fig:predicate} shows the \textsf{MatchingExpression}'s metamodel: it includes a matching expression for matching a class instance, a field value, a method call, or any logical combination of these elements. 
Note that data operators can be used for the \texttt{FieldOf} and \texttt{ParamOf} expressions. For example, \texttt{field\_of(D,age,$\leq$,18)} means that \textsf{D} is any instance whose value for the field \texttt{age} is less or equal than 18. 

\comments{
For example, the permission \textsf{R1} defines a context \textsf{fileOfPatientAssignedToDoctor} that needs to be precisely defined. Similarly, the \texttt{StaticMapping} for the action \textsf{delete} did not precise how the involved methods interact with each others. Dynamic Bindings take care of these tasks: Figure \ref{fig:predicate} defines a metamodel for patterns to be matched with the policy rules' status and the application's dynamic state. Recalling from Fig. \ref{fig:SpecificationLanguage}, \texttt{DynamicBinding} is either a \texttt{ContextBinding} or an \texttt{Operation\-Binding}. Both share the same structure: a \texttt{DynamicBinding} defines a \texttt{BindingExpression} formula for the binding, which refers to a \texttt{source} that performs an \texttt{action} on a \texttt{target}. Additionally, a \texttt{ContextBinding} references a \texttt{ContextId} to be defined. In the examples below, we will use a textual syntax to represent models, since text is more compact and closer to what experts use. A \textsf{ContextBinding} is represented by $\mathsf{\mathbf{hold}(source, action, target, contextId)} \leftarrow \mathsf{exp}$; and means that \textsf{contextId} holds for a concrete \textsf{source} acting on \textsf{target} if the \textsf{BindingExpression} \textsf{exp} is true. Similarly, an \textsf{OperationBinding} is represented by $\mathsf{\mathbf{operation}(source, action, target)} \leftarrow \mathsf{exp}$; it means that \textsf{action} is possible between \textsf{source} and \textsf{target} if  \textsf{exp} is true. 


Figure \ref{fig:predicate} describes \texttt{BindingExpression}, the expression language for defining dynamic binding. Compared to the metamodel of Fig. \ref{fig:dynamic-state}, it is very similar to \texttt{Event}'s subclasses, except that artifacts to be found in the dynamic state are replaced by placeholders (i.e. free variables). Note also that this language uses the usual boolean connectors (\textsf{Conj}unction and \textsf{Neg}ation classes). An \texttt{InstanceOf} maps an \texttt{InstanceVar} to an existing \texttt{Role} in the policy; a \texttt{FieldOf} maps an \texttt{InstanceVar} to a \texttt{Field} (name) and its \texttt{Value}, possibly using primitive operations (like arithmetic or boolean operations, collection operators, or primitive types operations). A \texttt{MethodCall} maps a method identifier with a method alias as defined in static mappings in Sec. \ref{sec:StaticRules}. Naturally, well-formed rules exist to ensure the correct specification of rules based on the Java and policy declarations (e.g., if a field is declared having type \textsf{int}, it has to be matched with an integer value). In the concrete syntax, the same words as their refering class are used.

We clarify the use of dynamic binding rules with a small example. Figure~\ref{fig:example-state} shows a partial snapshot of a possible state of the Medical System application: two doctors \textsf{Mary} and \textsf{John}, are assigned to patients \textsf{Ben} and \textsf{Natalia}, and \textsf{Sarah} and \textsf{Lionel}, respectively (as depicted in their internal box. The system also contains two files, identified by \textsf{File 101} and \textsf{File 102} that both contains information about \textsf{Natalia}.

\begin{figure}
	\center
	\resizebox{0.5\textwidth}{!}{\includegraphics{state2.pdf}}	
	\caption{Dynamic State Snapshot of a possible state of the application: two instances of \textsf{Doctor}s named \textsf{Mary} and \textsf{John}; two instances of \textsf{Patient} named \textsf{Natalia} and \textsf{Ben}; two instances of \textsf{File} both belonging to \textsf{Natalia}.}
	\label{fig:example-state}
\end{figure}

\paragraph{Context Rules} From Section \ref{sec:security-rules}, we want to define the contexts attached to Permissions \textsf{R1} and \textsf{R5}:

\medskip
\begin{scriptsize}
	\begin{sffamily}
\noindent
permission(r1, doctor, consult, file, fileIsPrivate \& fileOfPatientAssignedToDoctor).

\noindent
obligation(r5, doctor, delete, file, fileOfPatientAssignedToDoctor, delay(2y)).
\end{sffamily}
\end{scriptsize}

\medskip\noindent
In \textsf{R1}, the activation context is defined as a conjunction (noted \textsf{\&}) of two contexts \textsf{fileIsPrivate} and \textsf{fileOfPatientAssignedToDoctor}; \textsf{R5} share the context \textsf{fileOfPatientAssignedToDoctor}, with a additional delay of two years. The following predicates, expressed in a textual concrete syntax conforming to our metamodel of Figure \ref{fig:dynamic-state}, defines the necessary meaning attached to these contexts:

\smallskip\noindent
\begin{small}
			\begin{sffamily}
hold(\_,\_,T,fileIsPrivate) $\leftarrow$\\
\phantom{MMM}instanceOf(T,file), fieldOf(F,type,private).\\
\\
hold(D,\_,F,fileOfPatientAssignedToDoctor) $\leftarrow$\\
\phantom{MMM}instanceOf(F,file), fieldOf(F,patientName,N),\\
\phantom{MMM}instanceOf(D,doctor), fieldOf(D,patients,includes,N).
			\end{sffamily}
\end{small}

\smallskip\noindent 
The first definition has the form \textsf{\textbf{hold}(S,A,T,fileIsPrivate)}: it says that \textsf{fileIsPrivate} becomes active if it is possible to find a match for free variables \textsf{S}, \textsf{A} and \textsf{T} satisfying the expression (defined after $\leftarrow$). Note that here, \textsf{S} and \textsf{A} are left unspecified because they do not matter: they are replaced by $\_\_$ in the binding. The expression expresses the fact that \textsf{T} should be an \textsf{instanceOf} class \textsf{File}, whose field \textsf{type} has value \textsf{private}. 

In a dynamic binding, variables are only bound by the matching expression, so they can be freely chosen. For defining \textsf{fileOfPatientAssignedToDoctor}, we used more evocative variables. The pattern holds if it is possible to find a source corresponding to \textsf{Doctor} \textsf{D}, that has among the treated \textsf{patients} one patient \textsf{N} that corresponds to the \textsf{patientName} field value for the \textsf{File} \textsf{F}, which is the target of the binding. Here, \textsf{N} does not appear in the \textsf{\textbf{hold}}, but is only constraints within the expression. Notice that the second \textsf{fieldOf} has an extra component \textsf{includes}: in Figure \ref{fig:example-code}, field \textsf{patients} in class \textsf{Doctor} was actually typed as an array, so collection operators are required to iterate over its string values. 

Let us now apply the dynamic binding defining \textsf{fileOfPatientAssignedToDoctor} on the situation depicted in Figure \ref{fig:example-state}: the pattern matching resolves with $\mathsf{D} = \{\mathsf{Mary}\}$ and $\mathsf{F} = \{\mathsf{File101}, \mathsf{File102}\}$. Relatively to \textsf{R5}, this places two concrete obligations for \textsf{Mary} to delete these files within two years. Figure \ref{fig:policy-state} shows the effective \textsf{policy state} corresponding to the \textsf{application state} shown in Figure \ref{fig:example-state}. The application and policy state constitute the \textsf{state}.


\begin{figure}
	\center
	\resizebox{0.5\textwidth}{!}{\includegraphics{PolicyState.pdf}}	
	\caption{Policy State Snapshot: two obligations for \textsf{Mary} to delete \textsf{F 101} and \textsf{F 102}; and a permission authorizing \textsf{Mary} to consult \textsf{F 101}.}
	\label{fig:policy-state}
\end{figure}

Binding rules can also refer to the effective policy state. The policy state consists of a set of facts reflecting the state of security rules. For example, a fact \textsf{act\_obl(id,s,a,t)} holds in a policy state if a subject \textsf{s} has an obligation \textsf{id} to take an action \textsf{a} on a resource \textsf{t}. Therefore, in our example, two facts of this form will represent the two obligations shown in Figure \ref{fig:policy-state}. Using these policy state facts, it is possible to specify rules that depend on the states of other security rules. This is particularly useful in the case of obligations for the specification of sanction and reward policies.
For example, consider the activation context \textsf{violation\_r2} of the obligation \textsf{R3} from Section \ref{sec:security-rules}. This context should hold for a doctor \textsf{D} if he or she is in violation of the obligation rule \textsf{R2}. This may be specified by referring to the policy state in a context rule as follows:
 
\smallskip\noindent
\begin{small}
			\begin{sffamily}
hold(S,\_,\_,violation\_r2) $\leftarrow$\\
\phantom{MMM}viol\_obl(r2,S,\_,\_).\\
			\end{sffamily}
\end{small}

\noindent The context \textsf{violation\_r2} thus holds for a subject \textsf{S} if this subject is in violation of the obligation \textsf{r2} (since the fact \textsf{viol\_obl(r2,S,\_,\_)} holds in the policy state).

\paragraph{Operation Rules} Similar to the other abstract policy entities in our security metamodel, namely roles and contexts, \textsf{actions} need to be linked to the system model using \textsf{operation rules}. For example, we need to specify what it means that a \textsf{doctor} \textsf{consults} a \textsf{file} in our application domain.
The association of actions with entities of the target application is done using operation rules. An operation rule abstracts method calls into policy actions by specifying conditions on the application state, similarly to a context rule. For example, consider the method calls in Figure \ref{fig:methodCalls} showing the messages exchanged when a doctor is consulting a file. In this scenario, we may specify that the \textsf{doctor} (the operation subject) is the instance calling the method \textsf{consultFile} and that the \textsf{file} (the operation target) is the target instance of the method \textsf{viewFile} as follows:


\smallskip\noindent
\begin{small}
			\begin{sffamily}
operation(D,consult,F) $\leftarrow$\\
\phantom{MMM}callOf(consultFile), paramOf(consultFile,this,D),\\
\phantom{MMM}callOf(viewFile), paramOf(viewFile,target,F).\\
			\end{sffamily}
\end{small}

\begin{figure}[t]
	\center
	\resizebox{0.5\textwidth}{!}{\includegraphics{yehia.pdf}}	
	\caption{Method Calls for Consulting a File}
	\label{fig:methodCalls}
\end{figure}

\noindent Consequently, when some doctor \textsf{d} requests to consult some file \textsf{f}, an operation fact \textsf{operation(d,consult,f)} holds in the state. If this operation is authorized by the policy, then access is allowed, otherwise access is denied. The access control decision making logic is presented in the following section. 
}